1. Field of the Invention
This invention relates to networked systems, and specifically to an improved system, method, and computer-readable instructions for removing and returning nodes to a synchronous network.
2. Discussion of the Background
In high-performance automated machinery or plant there is a need for synchronous acquisition of measurements from networked sensors and for synchronous application of set-point values to networked actuators as this allows coordinated control and measurement. The synchronous measurement and synchronous application also permits loop closure via the network. The synchronous transfer of data to and from a central controller, and the necessity of establishing and maintaining synchronized clocks at each of the network slaves make special requirements on the network used in such a system; and although it is to some extent possible to use general purpose networks in such systems (See ANSI/IEEE Std 802.3 “CSMA/CD Access Method and Physical Layer Specifications” and BS EN 50325-4:2002 “Industrial communication subsystem based on ISO 11898 (CAN) for controller-device interfaces. CANopen”), it is advantageous for both cost and performance reasons to use special purpose, “real-time, cyclic networks”, that have been devised specifically for this purpose.
The defining characteristic of a real-time, cyclic network (hereafter abbreviated to “cyclic network”) is that, when the network is in its operational state, both “downstream” (from the controller) and “upstream” (to the controller) packets are scheduled according to a repeating timetable. The simplest scheme would be to send one downstream packet to each slave node per cycle (or alternatively one, composite packet to all slaves) and to receive one upstream packet from each slave node per cycle. There are many variations on this communication scheme, it is commonplace for the controller to emit a packet specifically for network timing purposes that is broadcast to all of the nodes, similarly it is possible to exchange more than one packet between the controller and each node on a cyclic basis. The period of the communication cycle is determined by software and hardware on the controller during network configuration and remains fixed during the operational phase of network operation. In general, shorter cycle times provide better control and therefore in a high-performance system there may be little or no idle network time.
In order to keep the terminology simple and consistent herein, the node that is responsible for configuring, controlling and supervising the network, i.e., the network master, will be referred to as the ‘controller’ because in most practical systems this is the element that is also responsible for overall system control. Again, for the sake of brevity, the remaining nodes on the network will be referred to simply as ‘nodes’ rather than slave nodes. The network is intended to carry out control or measurement or both on a machine, instrument or plant; to avoid repetition ‘control’ will embrace measurement and ‘system’ will be the network and that which is connected to it. Finally, communication with the network will be described as being carried in ‘packets’ in preference to the many alternative terms.
Cyclic networks provide cost-effective, high-performance control in many machines today. However in such networks the system must remain unchanged after the network has been initialized and brought into its cyclic, operational state. In general, it is not possible to add new nodes to an operational network, as would be advantageous in a machine that has modular structure where the modules can be brought into commission serially. Similarly it is not possible to remove a node and replace it while the network remains in its operational phase. In both cases, the machine would have to cease operation, the new nodes would then be added or replaced and the network would then have to be brought back into operation.
Therefore, there is a need in the art for a method and system that extends the capability of many cyclic networks so that it is possible to add nodes to an operational cyclic network, or to replace nodes within an operational cyclic network. This capability is often referred to in the literature as ‘dynamic removal and attachment’ or ‘hot-plugging’. The term ‘hot-replace’ may be used to cover the more restrictive case where nodes can be removed and subsequently re-attached or replaced but only up to the composition of the original set of nodes on the network.
There are a number of problems and limitations of the prior art due to two main pre-requisites to the implementation of hot-plugging on a cyclic network. The first would be to ensure that a physical communication link remains with all nodes while a node or group of nodes is being removed. The second would be to ensure that, when a node (or group of nodes) is added to the network, the packets sent from the node(s) to the controller do not disrupt existing network traffic.
Ethercat™ (See IEC PAS 62407 First edition 2005-06 Real-time Ethernet control automation technology (EtherCAT™), and U.S. Patent Pending Publication US2006/0212604A1 “Coupler for a ring topology network and an Ethernet-based network”) is a network that claims to support a form of hot-plugging, although the details of which have not been fully disclosed. Ethercat uses a logical ring topology, which is implemented as a physical line. Communication over this network is by means of a controller-initiated packet, which is modified on-the-fly by receiving nodes before being returned in this modified form to the controller. It is reasonable to infer, on the basis of the available information, that a node can discern when a neighboring node has been removed and can therefore automatically loop-back and likewise that said node can discern when a neighboring node has been attached and can therefore automatically change from loop-back to pass-through. Thus a node could be added to or removed from the end of a line of nodes with no or at least only temporary disruption to the circulating packet. As all packets are controller-initiated and modified by the nodes on-the-fly, there are no considerations of the timing of the reply packets since there are no such packets. Ethercat therefore offers a potential means of realizing the two main pre-requisites to the implementation of hot-plugging, however the solution is restricted both topologically (i.e., it only works where nodes are added or removed from the end of a line of nodes) and to a particular system of signaling (i.e., controller-initiated packets that are modified on-the-fly). Therefore, there still remains a need in the art for a system and method that escapes both of these limitations and is of more general applicability.
All other known examples of networks in the prior art have traffic organized so that, each communication cycle comprises one or more packets sent by the controller to the nodes and with one or more packets sent from each node to the controller.
In a cyclic network realized as a ring with unidirectional links, such as the typical embodiment of IEC61491 (IEC61491-2002 “Adjustable Speed Electric Drive Systems Incorporating Semiconductor Power Converters” (SERCOS™)), if a node or a group of nodes or any link is removed then communication fails either because packets emitted by the controller can not reach any of the nodes or because packets from some or all of the nodes can not reach the controller. In such a network, the reduced set of nodes can only be communicated with by re-wiring the remaining nodes into a ring and re-initializing the network.
In a cyclic network realized as a half-duplex or full-duplex bus, e.g., an alternative embodiment of IEC61491 using RS-485 (SERCON410B Datasheet© 1994 SGS-THOMSON), if a node or group of nodes is disconnected, it remains possible to communicate with the remaining nodes. However the problem remains of ensuring that, when nodes are added to the network, the packets that they send to the controller do not collide with existing network traffic.
In a cyclic network realized using hubs, e.g., Powerlink, if a node or group of nodes is disconnected it remains possible to communicate with the remaining nodes. Again the problem remains of ensuring that, when nodes are added to the network, the packets that they send to the controller do not collide with existing network traffic.
SynqNet® (See U.S. Pat. No. 7,024,257, U.S. Pat. No. 7,143,301) and also SERCOS™ III are full-duplex, cyclic networks that can be wired either as a line or as a ring. When a node or group of nodes is removed from the ring, the controller maintains full communication with the remaining nodes; this is termed ‘self-healing’. In both cases the problem remains of ensuring that, when nodes are added to the network, the packets that they send to the controller do not collide with existing network traffic.
Several networks support a mixture of cyclic and acyclic communication; typically each communication cyclic is divided into one or more time-slots reserved for scheduled, cyclic packets and one or more time-slots reserved for acyclic traffic types (hereinafter referred to herein as ‘asynchronous time-slots’). Example networks include SERCOS™ III, USB (Universal Serial Bus Specification Revision 2.0) and Powerlink (IEC PAS 62408 First edition 2005-06 Real-time Ethernet Powerlink (EPL)). In such networks it is possible to ensure that a node, which has been added to the network, at first communicates only during an asynchronous time-slot and thus does not disrupt exiting cyclic traffic; one method is for the node to reply to polled packets from the controller and another method is for the node to signal its presence by an event packet confined to an asynchronous time-slot. There are restrictions imposed by such schemes however. The first restriction is the necessity to reserve an asynchronous time-slot—at the expense of cyclic traffic. The second restriction is that the node must have some knowledge about where the time-slot is in time—typically this implies respecting a static timing restriction on when the node can send its reply or event packet with respect to a cyclic timing reference such as a timing packet—which may be operationally inconvenient. Accordingly, there is a need in the art to dispense with both of these restrictions. There is a need to avoid altogether the complication of having mixed traffic types and yet still ensures that when nodes are added to the network, the packets that they send to the controller do not disrupt existing network.